之前看 Rick And Morty 很喜歡裡面的這首主題曲 Moonmen

什麼是測試驅動開發（TDD）？

TDD 的核心理念與流程：
測試驅動開發（TDD）是一個迭代開發過程，在 test、coding 和 refactor 間快速循環。在 TDD 中開發人員首先依規格來撰寫應有行為的測試，再進一步撰寫程式碼來逐步通過測試，最後進行必要的重構。

TDD 優點

1. 提升程式碼品質
   TDD 框架鼓勵開發人員編寫簡單、乾淨、且有擴展性的程式碼，因此實踐 TDD 進而也會形成正面的迴圈，使有品質的程式碼成為開發中的一環。開發人員在實作新功能前要先深入思考其必要性和用途，並在撰寫單元測試時識別出定義不清的需求。
2. 強化系統品質
   編寫測試的過程強迫開發人員在產出程式碼前花更多時間考慮所有可能的「邊界情況」。相對於傳統的開發方法，能進一步降低錯誤的可能性。
3. 提高開發效率
   雖然 TDD 在前期撰寫程式碼的時間可能會增加，但從資源角度來看，初期解決問題比事後發現問題再花數倍時間解決來得划算。

五個基本步驟：

第一步：撰寫測試

• 在此階段，開發者需要先為將要開發的功能撰寫一個測試案例。由於功能尚未被實現，預期這個測試應該會失敗。

第二步：運行測試

• 接下來，運行剛剛寫的測試，預期它應該會失敗。

第三步：撰寫代碼

• 這一步中，目標是撰寫足夠的程式碼來讓上一步驟中失敗的測試通過。在這，焦點是「通過測試」，而不一定是完成整個功能的開發。

第四步：運行所有測試

• 寫出讓測試通過的程式碼後，接著運行所有相關的測試案例，確保新增的程式碼沒有導致其他功能出問題。

第五步：重構

• 最後，開始重構。在保持所有測試通過的前提下，優化並提升程式碼的可讀性和維護性。

完成以上五個步驟後，再對下一個開發的功能再次進行這個過程。透過這種方法在不間斷的開發過程中維持其程式可靠性和可維護性。

這邊補充和 TDD 相關的 BDD

什麼是行為驅動開發（BDD）？

行為驅動開發（BDD）的核心思想源自於 Dan North 在 2000 年代帶來的一種更新、更專注於用戶的測試驅動開發方法。相較於 Kent Beck 在敏捷開發早期所創 TDD，BDD 更注重使用一種 共享語言 來改善技術和非技術團隊成員間的溝通，並且將焦點聚焦在系統的行為上，進而確保測試是以用戶為中心。

BDD 的特色與應用

BDD 是從終端用戶的角度定義應用程式的功能表現。它提供了一種基於簡單、結構化的句子和利害關係人的母語（例如英語）來表達的通用語言。在BDD的實踐過程中，產品所有者、業務分析師和開發團隊（包含測試人員）會緊密協作並通過持續溝通來發現、理解並制定真正的業務需求。

BDD的實踐範例

以一個實際範例來看，我們可以瞭解到BDD如何協助開發人員寫出更具描述性的測試：

public class WhenTransferringInternationalFunds {
    @Test
    public void should_transfer_funds_to_a_local_account() {...}

    @Test
    public void should_transfer_funds_to_a_different_bank() {...}

    @Test
    public void should_deduct_fees_as_a_separate_transaction() {...}
    ...
}

這些以 BDD 「風格」撰寫的測試讀起來更像是一套規範，強調應用程式的行為，將測試作為表達和驗證該行為的手段。

TDD與BDD的區別

雖然 TDD 在具備足夠技術能力並熟悉使用的單元測試框架的情況下能夠發揮很大的效用，但 BDD 能夠透過更清晰、直接的語言撰寫出測試，提升技術和非技術團隊之間的協作效率。

• TDD（測試驅動開發）
  • 關注開發人員對功能的見解 -> developer 視角。
  • 驗證目標：確保功能實作正確無誤。
• BDD（行為驅動開發）
  • 關注用戶對應用程式行為的看法 -> user 視角。
  • 驗證目標：確認應用程式的行為是否符合用戶預期。